Open BoR guide by Fugue
Last update on 11/23/05

OpenBoR website at 
www.openbor.com
and
www.openbor.net

Additional resorces at
http://senileteam.segaforums.com/ (Official BoR website)
and
http://borrevolution.vg-network.com/ (BoR Revolution website)

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
NOTES:
In any OpenBoR text file, you can use
#
at the start of a line to mark the line as a comment. Comments do not affect the game in any way. They're there for your own reference. For instance, if I didn't have all my animations done but I wanted to test the ones I had, I might put
# <><><><><><><><><><><><>
# THIS ANIMATION IS NOT YET COMPLETE!
# <><><><><><><><><><><><>
in the file before incomplete animations. That way, I could see at a glance what animations I still needed.

BINARY values are any whole numbers from 0 to 1. In other words, it's either 0 or 1. Generally, 0 means "not true" or "not used," while 1 means "true" or "used." If not specified, it will default to 0. That's just the general case, though. There are some exceptions.
INTEGER values are any whole numbers from -2147483647 to 2147483647. For example, 0, 13, -12222. Some examples of not-integers would be 10000000000000000000000000, 1.1, -3.1415...
DECIMAL values are numbers. It's basically integers with the ability to have decimals. I'm no longer sure if any commands can use these. Does anyone know?

Many maximum and minimum values here are guesses. If you know an actual value for an incorrect number, please let me know right away!

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
MODELS.txt:
Options:
	ajspecial	(bi)
		~Determines the input for special attacks and whether or not players can block attacks.
		~If {bi} is set to 0, players use their special with the special key they have assigned and they cannot block.
		~If {bi} is 1, players can use the input for ATTACKBOTH as a special attack. They can also use a block animation, which will be used when the special attack button is pressed.
		~If {bi} is 1, but the player does not have a block animation, they can use their special with both the special key and ATTACKBOTH.

	autoland	{int}
		~{int} is either 0, 1, or 2, and changes how entities can land after being thrown.
		~0 is the default. Players can press up and jump when hittting the ground after being thrown by another player or an enemy to land safely.
		~1 means they can use up and jump for a safe landing when thrown by an enemy, but automatically land safely if thrown by another player. Pits will still be a danger, of course.
		~2 means players can't use a safe landing at all.

	colourselect {bi}
		~{bi} is a binary value.
		~If {bi} is 0, the game is normal.
		~If {bi} is 1, you can change your character's pallete on the select screen by pressing up and down to cycle through the remaps.
		~I do not know of any way to "hide" the fmap pallete. So if you use this, players can select your frozen pallete.
		~That's "colour" with a u, not "color".

	nocost	{bi}
		~{bi} determines when player's special attacks costs life. If set to 0, they always costs life. If set to 1, you'll only lose life if your attack actually hits something.

	noblink	{bi}
		~{bi} was a binary value (It could have been either 1 or 0. Defaulted to 0.)
		~If {bi} was 0, enemies flashed when they died.
		~If {bi} was 1, enemies would not flash when they died.
		~This command has been removed. This feature is now an option in the options menu.

	nofall	{bi}
		~{bi} was a binary value.
		~When {bi} was 0, enemies all fell down (they didn't take damage, though) when you respawned after dying.
		~When {bi} was 1, enemies didn't fall down when you respawned after dying
		~This command has been removed. This feature is now an option in the options menu.


Load/Know:
	know	{name}	{path}
		~{name} is a name that the game will use to identify the entity. 
		~{path} is the location relative to OpenBoR of the entity's .txt file.
		~These entities are only placed in memory when actually needed. Used for everything but FLASH.txt and heros.

	load	{name}	{path}
		~{name} is a name that the game will use to identify the entity. 
		~{path} is the location relative to OpenBoR of the entity's .txt file.
		~The entity is always in memory. Used for flashes, heros, weapon-holding heros, and hero's projectiles.

	~You don't need to load music, sound, system, or stage files. This is used only for entities.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
LEVELS.txt:
	nosame {bi}
		~Determines whether or not Player 2 and Player 1 can use the same character at the same time.

	noslowfx	{bi}
		~If set to 1, hit sounds will always play at the normal speed. Normally, the higher the damage of an attack, the slower it's hitsound plays.

	hiscorebg	{bi}
		~If set to 1, the high score screen will have a background. Normally, it's just text on black.

	lives {int}
		~The player will start with {int} lives.

	credits {int}
		~The player will start with {int} credits.

	single {bi}
		~Determines whether or not Player 2 can join in a game.

	set	{name}
		~Marks the start of a difficulty level.
		~{name} is the name of the difficulty which will be selectable from the difficulty select menu.

	p1life	{x}	{y}
		~Determines the position of player 1's life bar.
		~{x} and {y} are the number of pixels, right and down respectively, from the top left corner of the screen to the top left corner of the life bar.
		~The {x} position also is used as the {x} position of the player's name and score. 

	e1life	{x}	{y}
		~Determines the position of the life bar for the entity which most recently hit/was hit by/touched/interacted with Player 1.
		~{x} and {y} are the number of pixels, right and down respectively, from the top left corner of the screen to the top left corner of the life bar.
		~The {x} position also is used as the {x} position of the enemy's name. 

	p2life	{x}	{y}
		~Determines the position of player 2's life bar. 
		~Works exactly like p1life, except it affects player 2's bar instead.

	e2life	{x}	{y}
		~Determines the position of the life bar for the entity which most recently hit/was hit by/touched/interacted with Player 2.
		~{x} and {y} work exactly like they did for e1life.

	p1icon	{x}	{y}
		~Determines the position of player 1's icon.
		~{x} and {y} are the number of pixels, right and down respectively, from the top left corner of the screen to the top left corner of the icon.
		~The {y} position also is used as the {y} position of the player's name and score. 

	e1icon	{x}	{y}
		~Determines the position of the icon for the entity which most recently hit/was hit by/touched/interacted with Player 1.
		~{x} and {y} are the number of pixels, right and down respectively, from the top left corner of the screen to the top left corner of the icon.
		~The {y} position also is used as the {y} position of the enemy's name. 

	p2icon	{x}	{y}
		~Determines the position of player 2's icon.
		~Works just like p1icon, but for player 2.

	e2icon	{x}	{y}
		~Determines the position of the icon for the entity which most recently hit/was hit by/touched/interacted with Player 1.
		~Works just like e2icon, but for the entity most recently interacting with Player 2.

	lbarsize	{w}	{h}	{noborder}
		~Controls the size of lifebars.
		~This applies to players, enemies, items, etc. They will all have the same width, height, etc.
		~{w} is the maximum amount of health the bar can display on a single line. If an entity's health goes over this value, the life bar will wrap around and 'double up' on top of itself. Defaults to 100.
		~ 1 unit of health is 1 pixel long.
		~{h} is the height of the lifebar in pixels. Defaults to 5.
		~{noborder} turns on or off the border and shadow around life bars. {0} means there is, {1} means no outline or shadow.

	timeloc	{x}	{y}	{w}	{h}	{noborder}
		~Controls the position of the clock timer.
		~To change the font, you'll need to work with the font file, not this command.
		~{x} and {y} control how far right and down (respectively) the timer is from the top left of the screen.
		~{w} and {h} control the dimensions of the border placed around the timer. If your timer is being displayed under the border or is off-center, try editing this.
		~{noborder} turns on or off the outline around the timer. {0} means it's there, {1} takes it away.
	~The default values are 149, 4, 21, 20, and 0, respectively.

	ifcomplete	{bi}
		~Can be used to create 'secret' levels if {bi} is set to 1.
		~They aren't really secrets, as the players will still be able to see them on the menu, but they won't be able to select it until they've beaten the game at least once.

	custfade	{int}
		~{int} determines how long it takes for music to fade out.

	musicoverlap	{bi}
		~Determines if the music fades in and out when changing (1), or stops and restarts (0). Defaults to 0.

	z	{xmin}	{xmax}	{BGheight}
		~Changes the location of stage boundaries.
		~{xmin} is how high up entities can walk. It starts at the top and works down, so larger numbers mean less room. Defaults to 160.
		~{xmax} is how far down the character can walk. It also goes down from the top. Defaults to 232.
		~{BGheight} changes where the bottom of the background is drawn. Defaults to 160. By changing this value, you can make the background match an altered {xmin}.
		~This can be set once per level. You can change it between two stages. If you need to change it during a stage, you should combine it with the "wall" command in the stage itself.
		~You can spawn entities outside of this range, but once they enter the playing field they can't escape again.

	file	{path}
		~{path} is the location of a .txt file which describes a stage.

	scene	{path}
		~{path} is the location of a .txt file which describes a cutscene.

	next
		~This command doesn't need any arguments.
		~When this command is reached, the Stage Complete scene will play, and Scores will be tallied.

	scrollspeed	{spd}
		~{spd} was either 1 or 2. It determined how fast the screen scrolled when a player reached the edge of the screen.
		~This command has been removed. The screen will now automatically speed up if your character is fast enough.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
LIFEBAR.txt:
	~An optional file which can be placed in the same directory as MODELS.txt to change the color of lifebars.
	~{R}, {G}, and {B} are color values from 0 to 255 for Red, Green, and Blue. If you don't know what that means, try thinking of them as brightnesses. If you had 0 255 0, then there would be no red, no blue, and all green, so you'd have green. If you had 0 0 0, there wouldn't be anything, and you'd have black. 255 255 255 would be all of everything, so it'd be white. 255 0 255 would be red + blue = purple. 128 128 128 would be halfway between white and black, so it'd be grey.
	~If it still doesn't make sense to you, try opening up Microsoft Paint, go to Colors -> Edit Colors -> Define Custom Colors. Try messing around with the Red, Blue, and Green values. It works like that.
	~Setting a color to the transparent color doesn't actually make it transparent.
	~The color settings must match one of the colors in the default pallete exactly.

	blackbox	{R}	{G}	{B}
		~Determines the color of the 'shadow' around the lifebar and the bar at 500 health.

	whitebox	{R}	{G}	{B}
		~Determines the color of the outline around the lifebar and the bar at 600 health and up.

	color{#}	{R}	{G}	{B}
		~{#} must be 25, 50, 100, 200, 300, 400, or 500.
		~There's no space between "color" and {#} in color{#}.
		~{#} is the health value at which the color will be displayed
		~color500 is also used as the background of the lifebar, and is displayed with transparency.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
PAL.act:
	~This is the ingame pallete, but I'm not sure how to change it without using Photoshop.
	~If you need the pallette, but you can't read .act files, you can find a copy of the first 128 colors in the lobster's alt5.gif frame. Most other frames are missing many colors past 100.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Entity Files:
Header Data:
	name	{name}
	      	~{name} is the name given to the entity by default.
		~It is a string of 1 to 21 characters. You can actually use up to 40 characters, but the name will stretch off the screen or under the timer, making it look silly. You can also make the name even longer than that, but anything past 40 won't be displayed, so you'll really just be making your life harder.
		~Program will crash on accessing the entity if you try to put a space in the name. You can safely use an underscore (_) instead.
		~It is required- program crashes on access without it.
		~Used for Players, Enemies, Items, Projectiles, and obstacles. Basically, everything.

	type	{type}
		~{type}:	player:	The entity is a human-controlled player.
			enemy:	The entity is a CPU controlled enemy or enemy projectile.
			item:	The entity is a stationary item which can be picked up. Items can only give one bonus per item. In other words, you can't make one item that both gives 2000 points AND gives a 1-up.
			none:	The entity is a useless decoration.
			steamer:	The entity constantly spews the object called Steam upwards with alpha transparency.
			pshot:	The entity is a player's projectile weapon.
			obstacle:	The entity is a stationary blockade which can (normally) be destroyed.
			text:	The entity is a message object. When spawned, it will freeze all objects in play and show it's IDLE animation, then dissapear. It can be sped up by pressing attack or jump. Can be used for level intros, mid-level cutscenes, etc.
			trap:	The entity is an obstacle which cannot be attacked. It can be made to attack, though, and will hit both players and enemies. If a trap is not set up to knock the entity down, the trap will only damage the entity one time. To hit them again, the target entity must take damage from another entity.
			endlevel:	The entity is an item which, when touched by a player, will end the stage. It can be given a score value to be awarded for level completion.

	subtype	{type}
		~{type}:	arrow:	The entity flies from left to right off the screen. You can use the "flip" command when spawning it to make it fly right-to-left.
			noskip:	Used with text-type entities. It prohibits the player from using attack or jump to skip through text.
			weapon:	Used for player weapons which can be picked up and used.
			biker:	Used for Biker enemies. They fly left and right across the screen and must be knocked off their bikes to be stopped.
			notgrab:	Does the same thing as the nograb command: the entity can't be grabbed.
			touch:	For items. The item will be collected just by touching it. You won't need to press the attack button.
			flydie:	For obstacles. When hit, the obstacle will fly horizontally offscreen while playing it's FALL animation.
			both:		For endlevel items. If there are two players, both must be touching this item to end the stage.

	health	{int}
		~{int} is an integer, a number from -2147483647 to 2147483647 (which also happens to be (2^31)-1, if you're a math fan).
		~Do not actually put a boss with 2147483647 health in your game. It's not funny.
		~You can use decimal numbers, but it will always round down, so there's no real point.
		~If you use a value less than one or greater than 2147483647, the enemy starts off dead. Now that IS funny, but not neccessarily useful.
		~If the number is over 100, the meter will "double up" the display. This can make it hard to tell how much life an enemy has remaining sometimes.
		~Not required, but it defaults to zero if it's not there, so that's kind of useless if you don't set it in the level's spawn point.
		~Used for players, enemies, items, projectiles, obstacles.
		~For items, this tells you how much life you regain when you pick it up.

	speed	{int}
		~{int} is a number from 5 to 300.
		~You can use numbers less than 5, but the entity will still move at the same speed. Same with using more than 300.
		~Somewhere between 100 and 300, the entity will gain the ability to run off the screen edges and out of the play area, killing it instantly. So that might not be a good idea.
		~Setting this to 0 will not stop an enemy from moving. You must use 'nomove' to do that.
		~Used for players, enemies, projectiles, and arrows.

	running	{speed}	{height}	{length}	{move}	{land}
		~Determines the character's running abilities.
		~Used for players.
		~If present, players can run by pressing left or right twice and holding the button. The free special attack's input also changes to left, right, attack and right, left, attack.
		~If this is not present, the character will be unable to run.
		~{speed} is an integer value which works just like speed.
		~{height} determines how high a character can jump (if at all) while running. It works like jumpheight.
		~{length} is an integer value which changes how far a character can jump while running. It is multiplied by the current jump length.
		~{move} is a binary value. It defaults to 0, which means the character stops running if they press up or down. If set to 1, the character will continue running, but will also move up or down at an angle.
		~{land} is a binary value. 0 means they stop running after landing from a running jump. 1 means they can continue running if the player holds forward during the jump.

	nomove	{move}	{flip}
		~Can be used to make a stationary enemy (one who does not move).
		~{move} is a binary value which determines if the enemy can or can't move. Setting it to 0 doesn't do anything, but setting it to 1 stops the enemy from moving.
		~{flip} is a binary value which determines if enemies can turn around to face players behind them.
		~If {move} is set to 1, the enemy's speed will default to 0.

	jumpheight	{int}
		~{int} is an integer value which determines how high an entity jumps.
		~The default value is 4.
		~An entity's jumpheight also affects how far it flys when knocked down, how high and far jumpframe moves you, and how far another entity will fly if this entity grabs them and throws them.
		~For Bomb entities, this controls how high the bomb arcs into the air.

	grabdistance	{int}
		~{int} determines many things:
			~How close this entity must be to another to grab it.
			~How far away this entity will stand while holding an enemy.
			~How deep this character's attack range is (the range which can be changed with 'z' in LEVELS.txt).
			~How close this entity must get to be stopped by obstacles or pick up items.
			~How close other entities must be to be damaged or blocked by this trap/obstacle.
		~The default value is 36.

	height	{alt}
		~Affects an entity's ability to walk under platforms.
		~If the platform is higher off the ground than this entity's height, this entity can move under it. Otherwise, it will get pushed out.
		~Measured from the offset point up.
		~This can only be set once per entity, so test it under multiple animations to make sure nothing goes wrong.

	secret	{bi}
		~Used to make a 'secret' character who must be unlocked.
		~Secret characters are unlocked after beating any difficulty setting once, and can only be used in 'secret' difficulty levels.

	shadow	{int}
		~{int} is a number from 0 to 6.
		~Each number corresponds to a specific shadow in the SPRITES folder.
		~Normally, the lower numbers are smaller.
		~This determines which shadow graphic will appear centered at this entity's offset point.
		~0 means there won't be a shadow.

	fmap	{int}
		~{int} is a number from 1 to 14 which tells the game what color to make the entity if it gets frozen by an attack.
		~{int} is the number of a remap pallette.

	load	{name}
		~{name} is the name of an enemy which will be shot as a projectile.
		~The projectile's type should be "enemy".
		~The projectile must be named "shot", "knife", or "star". If you don't want to use those names (or they're already used), use the knife, star, and fireb commands.

	knife	{name}
		~Used like "load". {name} will be thrown like a knife.
		~You'll need to use "load {name} {path}" instead of "know {name} {path}" when declaring the projectile in models.txt.
		~Knives can't be used during a jump. Use firebs or stars instead.

	fireb	{name}
		~Used like "load". {name} will be launched like a shot.
		~You'll need to use "load {name} {path}" instead of "know {name} {path}" when declaring the projectile in models.txt.

	star	{name}
		~Used like "load". {name} will be flung like a ninja star in a jump.
		~This command actually causes three stars to be thrown at three different angles. If you only want one, change a fireb projectile to look and fly downward like a single star.
		~You'll need to use "load {name} {path}" instead of "know {name} {path}" when declaring the projectile in models.txt.
		~Stars can only be used during a jump.

	bomb	{name}
		~This only works for enemies. It is different from the "bomb" command used by heros.
		~Used like "load". {name} will be tossed out like a grenade.
		~Bombs start off playing their IDLE animation until one of three things happens:
			1:	The bomb touches a player
			2:	The bomb is hit by an attack
			3:	The bomb touches the ground
		~After 1 or 2, the bomb will play it's ATTACK1 animation. 
		~After 3, the bomb will play it's ATTACK2 animation.
		~After playing it's attack animation, the bomb will disappear.
		~Bombs are thrown in an arc determined by their speed and their jumpheight.
		~You'll need to use "load {name} {path}" instead of "know {name} {path}" when declaring the projectile in models.txt.

	hitenemy	{bi}
		~For enemy's projectile entities.
		~If {bi} is 1, this entity can hit other enemies, even if they threw this. Obviously, it still can hit players as well.
		~If {bi} is 0, this entity can only hit heros.

	playshot	{name}
		~{name} is the name of a "pshot"-type entity.
		~The player shoots this with pshotframe #.
		~Except for the initial word (playshot instead of load), this is used exactly like an enemy projectile.

	flash	{path}
		~{path} points to a .txt file defining a flash animation.
		~This is played when this entity is hit, not when it hits another entity.

	bflash	{path}
		~{path} points to a .txt file defining a flash animation.
		~This is played when this entity blocks an attack.

	nolife	{bi}
		~Determines whether or not the player can see the entity's life when they make contact.
		~0 means they CAN see it. Defaults to 0.
		~1 means they CANNOT see it.

	noquake	{bi}
		~Determines whether or not the screen shakes if the entity hits the ground after being thrown.
		~0 means it shakes. Defaults to 0.
		~1 means it doesn't shake.

	nodrop	{bi}
		~Set it to 1 to stop this entity from falling unless they die and:
			1: They have no DEATH animation
			2: They have a DEATH animation, and its 'falldie' flag is set to 1.

	makeinv	{int}
		~Determines whether or not the character is briefly invincible after being respawned. Otherwise, traps and enemies may be able to attack the player as they reappear- not nice.
		~(int) is how many seconds the player will be invincible for.
		~{int} also controls how long the parrow and parrow2 are visible.

	blockodds	{int}
		~{int} is a number from 1 to 2147483647. It determines how often an enemy will block an attack.
		~1 means they'll block almost all attacks. 2147483647 means they pretty much never, ever, ever block, ever.
		~Enemies can't block during attacks.

	thold	{int}
		~{int} is the threshold for an entity's blocking ability.
		~If the entity tries to block an attack with an attack power higher than {int}, they will not be able to do so and will get hit anyway.
		~If {int} is 0, an entity will have infinite threshold. In other words, they can block any attacks.
		~Regardless of threshold, if an attack is set to be unblockable, it can't be blocked.

	falldie	{bi}
		~If set to 0, the enemy uses the DEATH animation as soon as they die.
		~If set to 1, when killed, the enemy plays the FALL animation until they stop moving, then play the DEATH animation.

	icon	{path}
		~The graphic normally shown next to the entity's life bar.
		~Normally a 16 x 16 box with a picture of the entity's head.
		~The position of the graphic can be changed in LEVELS.txt.
		~You can use a longer image to change the appearence of your character's lifebar, but remember that the box and shadow around it appear on top if you don't turn them off in LEVELS.txt.
		~Dimensions of the life bar relative to the icon in bbox format (if you haven't changed it in LEVELS.txt):
			18	8	103	9

	iconpain	{path}
		~Same as icon, except this appears instead if the entity is being injured.
		~This only works for players.

	icondie	{path}
		~Same as icon, except this appears instead if the entity is dead.
		~This only works for players.

	iconget	{path}
		~Same as icon, except this appears instead if the entity is picking up an item.
		~This only works for players. Not like anything else has a GET animation.

	diesound	{path}
		~{path} points to a .wav file that plays if the entity is defeated.
		~As with all .wav files, MAKE SURE TO KEEP THE FILE SIZE DOWN! Open the file with Microsoft Sound Recorder and cut off any blank or unneeded sections of the file. .wav is a large file format, don't waste all your mod's memory on it!

	parrow	{path}	{x}	{y}
		~When a player respawns, the image at {path} will flash over the player at {x},{y} compared to their offset.
		~The image will be visible for as long as the player is invincible after respawning (determined with makeinv).
		~I use -48 -130 for mine. You'll probably want yours to be somewhere around there, but I doubt you're using the exact same image and entity, so experiment.

	parrow2	{path}	{x}	{y}
		~If player 2 is playing, and respawns, this will appear instead of parrow. You could just use parrow over again, or you could use something to mark that this is Player 2, not Player 1.

	score	{onkill}	{multiplier}
		~Changes the score earned by killing this entity. Both {onkill} and {multiplier} are {int}s.
		~When the entity dies, the player who killed him/her/it will get {onkill} bonus points to their score.
		~Any hits landed on this entity by a player which would increase the player's score is multiplied by {multiplier}.
		~The default value is 5 for the multiplier.
		~When used with an item, {onkill} changes the amount of score added when the item is picked up and {multiplier} is not used.

	bomb	(power)	(type)	(pause)	(length}
		~This is for players. Enemies use the 'bomb' command for something else.
		~If this is present, the player's special will work differently: it will become a "smart bomb" which damages all onscreen enemies, regardless of position.
		~{power} is an integer value which determines attack damage.
		~{type} is the attack's effect type:	0	knockdown
									1	blast
									2	burn
									3	freeze
									4	shock
									5	steal
		~{pause} is a binary value which determines whether or not all action onscreen pauses when you use your special. Used for a dramatic effect.
		~If {type} was set to 3 (freeze), {length} can be used to determine how long the enemies will remain frozen.
		~This command can also be used for items. In this way you can make "smart bomb" items to clear the screen. If you do use it with an item, {length} will replace {pause}.
		~Exactly what is so smart about a bomb that just hits everything, anyway?

	toflip	{bi}
		~Used for hitflashes.
		~If {bi} is 0, this hitflash will always face the same direction when spawned. If set to 1, the hitflash will flip when the attack comes from the other side.

	cantgrab	{bi}
		~{bi} determines whether or not an entity can be grabbed and held (or thrown). 

	noatflash	{bi}
		~When {bi} is 1, this entity will always play it's personal 'flash' when hit, instead of the attacker's. Useful for obstacles.

	remove	{bi}
		~Only works for projectiles. Defaults to 1.
		~If 1, the projectile will be destroyed when it hits an enemy.
		~If 0, the projectile continues flying even after hitting an enemy.

	com	{dir1}	{dir2}	{action}	freespecial{#}
		~Allows you to customize freespecial input commands.
		~The {#} should be the number of the freespecial you want to change. You can leave it blank for 1 or use 2 though 8 for 2 through 8.
		~There is no space between freespecial and {#}.
		~The input will become {dir1}, {dir2}, {action}.
			~{dir1} or {dir2}:	U:	Up
							D:	Down
							B:	Back (The direction opposite your current direction. If used, the character will turn around.)
							F:	Forward
			~{action}:		A:	Attack button
						J:	Jump button
						S:	Special attack button
						K:	Alternate special attack button
		~You can use either S or K for the special attack button commond. You can only use one or the other, so pick one and stick with it. This was done so that modders who use the special key for blocking can remember the key is used to blocK, not use Specials. (B would have been used, for Block, but B is already used for Back.)
		~Make sure that you don't have any conflicts with other commands. RUN, DODGE, and the directional ATTACKs all have inputs which can be the same as freespecials.
		~If you use B for {dir1}, flip the next input. The player changes direction, remember? So B, F, A would be 'turn around, move forward, attack', but since you turned around first, moving forward would mean moving in the direction you just turned to. If you wanted to have an input like Street Fighter's Guile or Charlie's Sonic Boom, you'd need to use B, B, A instead of B, F, A.

	remap	{path1}	{path2}
		~Allows you to create alternate palletes for entities.
		~Each entity can have up to 14 palletes.
		~{path1} is a sprite of an entity in their normal pallete. {path2} is a sprite of the entity in an alternate pallete. 
		~You should not change the file's pallete. The only changes should be to the pixels in the image, not the pallete data.
		~Player 2 normally uses the first alternate pallete, but both players can select their color when choosing a character with up and down if the colourselect option is on.
		~If your entity has sprites with incorrect colors in alternate palletes, the entity may use colors which are not in {path1}. Check the frames with incorrect colors and compare them. Then just add the colors somewhere in {path1} and the new colors in the same position in {path2}. If that sounds confusing, look at K9999's remaps. That's what I mean.

Animation Types:
	WAITING	(used for players)
		~An optional animation.
		~Plays on the character select screen when a character is highlighted (that is, pressing an attack button will select them).

	SELECT	(used for players)
		~An optional animation.
		~Played when you select a character on the character selection screen (that is, you've pressed an attack button to indicate you want to use this character).

	SPAWN	(used by players and enemies)
		~An optional animation.
		~Plays when an entity appears in a level, whether from the level's .txt file or being respawned after dying. It also plays on the character select screen.
		~It generally beats having new enemies just fall from the sky. That looks kind of silly with most enemies.

	RESPAWN
		~This does the exact same thing as SPAWN. You can use them interchangeably.

	IDLE	(all)
		~The animation for when something is just standing there.
		~If an entity isn't moving, attacking, dodging, grabbing, or dying, they're probably doing this.
		~If the SELECT and SPAWN graphics are not present, the IDLE animation will be used instead.

	WALK	(players, enemies)
		~Optional for non-moving enemies.
		~The animation for an entity walking left or right.
		~If a character does not have UP and DOWN animations, they will use this instead when walking up or down.

	UP	{players, enemies}
		~Optional.
		~Played when the character walk up, up-left, or up-right.
		~For this animation to work correctly, it must have the same number of frames as the WALK animation.

	DOWN	{players, enemies}
		~Optional.
		~Played when the character walk down, down-left, or down-right.
		~For this animation to work correctly, it must have the same number of frames as the WALK animation.

	LAND	(players)
		~Optional, but players may still be able to land safely depending on the 'autoland'settings in MODELS.txt.
		~If a player is thrown by an enemy (Thrown, not knocked down), then they can press Up and Jump right when they hit the ground to recover instantly and take no damage. This animation will be played instead of the normal fall animation.

	RUN	(players)
		~Optional.
		~If the player has their running speed specified, this is the animation they will use to run.
		~By setting loop to 0 and adding in the jumpframe command, you can turn this into a dash animation. The player will leap forward.

	RUNATTACK	{players}
		~Optional.
		~Requires the character to be able to run. Otherwise, they can't really use it.
		~If the player presses attack while running, they will perform this attack.

	RUNJUMPATTACK	{players}
		~Optional.
		~Requires the character has a RUN animation. Otherwise, they can't really use it.
		~If the player presses attack during a running jump, they will perform this attack.

	BLOCK	(enemies, players)
		~Optional.
		~For players, this animation will only play if 'ajspecial 1' is in MODELS.txt. It will play when the player presses the special attack button.
		~Enemies use this with 'blockodds {int}'. If an enemy blocks your attack, they will play this animation.
		~Enemies will only block an attack if it would otherwise hit them (i.e. they won't block an attack which goes 10 feet over their heads).

	DODGE	(players)
		~Optional.
		~Players with this animation can perform a 'depth' dodge up or down by pressing up or down twice.
		~The player will move along the z axis (closer to or farther from the screen).
		~The dodge will last as long as the animation does, and you can't cancel out of it by attacking. So don't set it to loop.
		~This cannot be used with ATTACKUP, ATTACKDOWN, or freespecials with the input U, U or D, D.

	GET	{players}
		~Optional.
		~Played when the character picks up an item.

	ATTACK1	{players, enemies}
		~An attack. Players perform this by pressing attack.
		~Enemies randomnly perform this attack when a player is in range (range is specified with the 'range' command).
		~Enemies are slightly more likely to use ATTACK1 than ATTACK2, and slightly more likely to use ATTACK2 than ATTACK3.
		~Enemy bombs play this animation if they touch the ground. If they don't have an ATTACK2 animation, they'll use this instead, as well.

	ATTACK2	{players, enemies}
		~Another attack. Players use this if they press attack after hitting with ATTACK1 twice.
		~Enemies use this just like ATTACK1.
		~Enemy bombs play this animation if they touch another entity's bbox or attack box.

	ATTACK3	{players, enemies}
		~And another attack. Players use this if they press attack after hitting with ATTACK2.
		~Players can also use this by holding attack for three seconds and then letting go.
		~Enemies use this just like ATTACK1 and ATTACK2.

	ATTACKBOTH	{players}
		~An attack. Players use this if they hold attack and then press jump.
		~This cannot be used if the player has a BLOCK animation. If MODELS.txt has 'ajspecial 1', this is replaced by the special attack.

	UPPER	{enemies}
		~Optional.
		~If a player is on the same row as an enemy with an UPPER animation and jumps, the enemy will perform this attack automatically.
		~Don't try to use the range command with this attack. Enemies know when to use it (when someone jumps at them!).

	JUMP	{players, enemies}
		~Plays when a player presses jump or when an enemy approaches a platform.
		~You don't need to draw the entity moving upward, since BoR moves them automatically.
		~If given to an enemy, this animation should also have a range listed.

	JUMPATTACK	{players, enemies}
		~An attack.
		~For players, this is the attack performed when a player jumps and presses attack.
		~Enemies randomnly perform this attack when a player is in range.
		~The jump is automatic. You don't need to use the jumpframe command or draw the entity moving forward.
		~When enemies use this attack, they'll jump forward.

	JUMPFORWARD	{players}
		~Optional.
		~If a player has this animation, they will only play their JUMPATTACk animation if they jump straight up and attack. This attack will be used if they jump forward and attack.

	JUMPATTACK2	{players, enemies}
		~An attack. Just like the normal JUMPATTACK, except that players perform this attack by jumping, then holding the down button and pressing attack.
		~Enemies randomnly perform this attack when a player is in range.
		~When enemies use this attack, they'll jump straight up.

	JUMPATTACK3	{players}
		~Optional.
		~An attack. Just like the normal JUMPATTACK, except that players perform this attack by jumping, then holding the up button and pressing attack.

	ATTACKUP	{players}
		~Optional.
		~An attack. Players perform this by pressing up twice.
		~This attack overrides freespecials. If you use it, you will not be able to use a freespecial which has Up, Up, {button} as it's input. You also can't use this attack if you use the DODGE animation.

	ATTACKDOWN	{players}
		~Optional.
		~An attack. Players perform this by pressing down twice.
		~This attack overrides freespecials. If you use it, you will not be able to use a freespecial which has Down, Down, {button} as it's input. You also can't use this attack if you use the DODGE animation.

	ATTACKFORWARD	{players}
		~Optional.
		~An attack. Players perform this by pressing forward twice.
		~This attack cannot be used with running. Also, if you use it, you will not be able to use a freespecial which has Forward, Forward, {button} as it's input.

	ATTACKBACKWARD	{players}
		~Optional.
		~An attack. Players perform this by pressing backwards once, then quickly pressing attack.
		~Unlike most attacks which use the back button, this does not flip your direction.

	FREESPECIAL{#}	{players}
		~Optional.
		~If {#} is not placed on the end of the name, it references FREESPECIAL1. If {#} is a number from 2 to 8, it references that FREESPECIAL. Anything else is an error.
		~There is no space between FREESPECIAL and {#}.
		~An attack. The input depends on the 'com	{dir1}	{dir2}	{action}	freespecial{#}' earlier in the .txt file.
		~FREESPECIAL defaults to F, F, A if you can't run and B, F, A if you can. FREESPECIAL2 defaults to D, D, A. FREESPECIAL3 defaults to U, U, A. The other FREESPECIALs don't default to anything, and thus need to be defined to be useable.

	SPECIAL	{players, enemies}
		~Optional for enemies.
		~A breakout attack.
		~Players perform this by pressing special. They can use it while being held by an enemy to break free, or while playing an injured animation (besides fall, shock, burn, and death) to counterattack.
		~For players to use this attack, they must have at least 6 life, which they will lose upon performing the attack. You can change this with 'energycost'.
		~Enemies perform this attack automatically if a player grabs and holds them for too long without throwing them or knocking them down.

	SPECIAL2	{players}
		~Optional.
		~Players perform this by pressing forward and special, or special while running.

	GRAB	{players, enemies}
		~Optional for enemies, can be made optional for players with nograb or notgrab.
		~When this entity moves close enough to another, this entity will grab hold of the other.
		~If a player grabs an enemy, they can hold the direction opposite the enemy for a few seconds to let go and walk away.

	GRABATTACK	{players, enemies}
		~Optional for enemies, can be made optional for players with nograb or notgrab.
		~When you've grabbed another character, you can press attack to use this attack up to two times.

	GRABATTACK2	{players, enemies}
		~Optional. If not defined, defaults to ATTACK3.
		~When you've grabbed another character and used GRABATTACK twice, you can press attack to use this attack.
		~You can also use this early by pressing jump.

	GRABFORWARD	{players}
		~Optional.
		~When you've grabbed another character, you can press forward and attack to use this attack up to two times. Just like GRABATTACK except for the input.

	GRABFORWARD2	{players}
		~Optional. If not defined, defaults to ATTACK3.
		~When you've grabbed another character and used GRABFORWARD twice, you can press forward and attack to use this attack.
		~You can't use this early by pressing jump and forward.

	GRABUP	{players}
		~Optional.
		~When you've grabbed another character, you can press up and attack to use this attack up to two times. Just like GRABATTACK except for the input.

	GRABUP2	{players}
		~Optional. If not defined, defaults to ATTACK3.
		~When you've grabbed another character and used GRABUP twice, you can press up and attack to use this attack.
		~You can't use this early by pressing jump and up.

	GRABDOWN	{players}
		~Optional.
		~When you've grabbed another character, you can press down and attack to use this attack up to two times. Just like GRABATTACK except for the input.

	GRABDOWN2	{players}
		~Optional. If not defined, defaults to ATTACK3.
		~When you've grabbed another character and used GRABDOWN twice, you can press down and attack to use this attack.
		~You can't use this early by pressing jump and down.

	THROW	{players, enemies}
		~Optional for enemies, can be made optional for players with nograb or notgrab.
		~When you've grabbed another character, you can press back and attack to use this attack.
		~This causes preset damage (21 points). You cannot change the damage, angle, or direction. Okay, you can kinda change the angle and distance with jumpheight.
		~The damage from this attack is not dealt until the victim lands. If they are a player and have a LAND animation, they can recover by pressing Up and Jump right when they land and avoid damage completely!

	GRABBED	{players, enemies}
		~Optional. Defaults to the PAIN animation if not present.
		~Plays when this character is grabbed by another.

	PAIN	{players, enemies}
		~Played when an entity is hit by an attack which does not knock them down. Obstacles do not use this.

	SPAIN	{players, enemies}
		~Optional. Defaults to PAIN.
		~No, not Spain. It stand for Shocked PAIN.
		~Played when an entity is hit by a shock attack which does not knock them down. 

	BPAIN	{players, enemies}
		~Optional. Defaults to PAIN.
		~This means Burned PAIN.
		~Played when an entity is hit by a burn attack which does not knock them down. 

	FALL	{players, enemies, obstacles}
		~Played when an entity is hit by an attack which knocks them down, or an attack while in air or frozen.

	RISE	{players, enemies}
		~Played when an entity who has FALLen down gets back up.

	RISEATTACK	{enemies}
		~Optional.
		~Played if a player is in range of the attack when an enemy who has FALLen down gets back up.

	SHOCK	{players, enemies}
		~Optional. Defaults to FALL.
		~Played when an entity is hit by a shock attack which knocks them down, or a shock attack while in air or frozen.

	BURN	{players, enemies}
		~Optional. Defaults to FALL.
		~Played when an entity is hit by a burn attack which knocks them down, or a burn attack while in air or frozen.

	DEATH	{players, enemies, bombs}
		~Optional.
		~Played when an entity loses all it's life.
		~If an entity is killed by being thrown, they will not use this animation.

	HITWALL	{enemies, players}
		~Removed. No longer valid.
		~If an entity has this animation, when they hit a wall after being thrown or flung, they would hang on the wall for about two seconds before sliding down.
		~This didn't work for screen edges, just for the ends of stages with the blocked command.
		~This animation has been removed. It no longer works.

	SLIDE	{enemies}
		~Useless. I guess that's kind of like Optional.
		~This doesn't actually do anything. It is there, though.
		~You can check it in the source code, or by just putting in the command and noticing it doesn't consider it an illegal animation. It still won't do anything.

Animation Data:
	loop	{bi}
		~Determines whether or not an animation repeats itself when finished.
		~0 means the animation ends when the last frame is reached.
		~1 means the animation repeats itself after the last frame.
		~You can change it during the animation, but there's not really much of a point...
		~Some animations should NOT be set to loop. Examples include most attacks and injured animations.

	fastattack	{bi}
		~Normally, in order for an attack to hit entities multiple times, the attack boxes must be separated by at least one frame with an empty attack box (one set to all 0) and must also be separated by a brief delay.
		~If this is set to 1, this animation's attack boxes are not restricted by the delay (it will still need an empty attack box between frames, though).

	hitfx	{path}
		~{path} should point to a .wav file.
		~If this animation has an attack box which makes contact with a victim, this sound will play instead of the normal 'beat1.wav' sound.
		~Like the normal hitsfx, the higher the attack power, the slower this sound will play.

	hitflash	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If this animation has an attack box which makes contact with a victim, this hitflash will play instead of the normal hitflash for this character.

	custpshot	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If present, for this animation only, the player's default 'playshot' entity will be replaced with this entity.
		~You still need to fire the entity at some point in the animation for this to do anything.
		~Don't forget to load the entity in MODELS.txt!

	custknife	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If present, for this animation only, the enemy's default 'knife' entity will be replaced with this entity.
		~You still need to fire the entity at some point in the animation for this to do anything.
		~Don't forget to load the entity in MODELS.txt!
		~Knives can't be used during a jump. Use firebs or stars instead.

	custstar	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If present, for this animation only, the enemy's default 'star' entity will be replaced with this entity.
		~You still need to fire the entity at some point in the animation for this to do anything.
		~Don't forget to load the entity in MODELS.txt!

	custfireb	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If present, for this animation only, the enemy's default 'fireb' entity will be replaced with this entity.
		~You still need to fire the entity at some point in the animation for this to do anything.
		~Don't forget to load the entity in MODELS.txt!

	custbomb	{name}
		~{name} is the name of an entity declared in MODELS.txt.
		~If present, for this animation only, the enemy's default 'bomb' entity will be replaced with this entity.
		~You still need to fire the entity at some point in the animation for this to do anything.
		~Don't forget to load the entity in MODELS.txt!

	delay	{int}
		~{int} is a number that tells how slowly the animation plays. 1 is extremely fast, past 25 will go very slow.
		~{int} is measured in centiseconds, or hundredths of a second. Pretty fast.
		~Can be used multiple times in one animation to change speed mid-animation

	offset	{x}	{y}	
		~Determines where the "base" of the animation is.
		~The center of the entity's "shadow" graphic is placed here if the player is on the ground. Also used by enemies to find where you are.
		~'offset	0	0' would be the upper left corner. Larger {x} values move the {x} down. Larger {y} values move the {y} right.
		~You can use negative numbers or numbers outside of the frame's edges.
		~Most entities will automatically die if their offset goes more than 80 pixels offscreen left or right (their x value must stay between -80 and 400). Knives are the only exception: they can go up to 180 either way (-180 to 500).
		~Common symptoms of incorrect offsets are misplaced shadows, sudden "warps" to different positions and back, and enemies/shadows who seem to think you're ten feet away.
		~Can be used multiple times in one animation to change position mid-animation

	bbox	{x}	{y}	{right}	{down}
		~Determines where the entity can be hit.
		~{x} and {y} are the x and y coordinates of the top left corner of the box, starting from the top left corner of the frame and moving right/down. {right} is how far to the right of {x} the box extends. {down} is how far down from {y} the box extends.
		~You can use negative numbers or numbers outside of the frame's edges. This can save a bit of memory by shaving a few excess rows or columns of pixels off an animation.
		~Can be used multiple times in one animation to change hittable areas mid-animation.
		~To give an entity frames where they cannot be hit, use 'bbox	0	0	0	0'. Be sure to add a new bbox when the entity is vulnerable again.
		~For items, this determines where the object can be picked up from.

	frame	{path}
		~{path} points to a graphics file to be used in this animation.
		~The frame will be displayed at the entity's position. It's about as simple as it sounds.
		~OpenBoR uses 256-color (or lower) .bmp, .gif, or .pcx files. However, .gif files are far and away the smallest, so please, please, don't use .bmp or .pcx, just .gif.

	range	{min}	{max}
		~Used for enemy attacks and jumps.
		~This command lets the enemy know when to perform their attacks or to jump on platforms..
		~For the enemy to use the attack, a player must be more than {min} away, but less than {max} away.
		~For the enemy to jump on a platform, the enemy must be within {min} pixels of the platform, and the platform must be less than {max} pixels high.
		~This is measured in pixels, starting at the enemy's offset point and moving towards the player's offset.
		~If not included, this will default to 0,0. This means that enemies will use the attack only when a player is between 0 and 0 pixels away. As in, right on top of them. Probably not very useful.

	attack	{x}	{y}	{right}	{down}	{damage}	{knockdown}	{block}	{noflash}	{pausetime}
		~An attack box which can hit bboxes.
		~You can only have one type of attack box per frame (that is, you can't have two attack boxes or a blast and a burn box in the same frame). You can 'fake' an extra box or two by adding in extra frames with different boxes and changing the delay accordingly, but this takes up more memory (for the extra frames) and doesn't work perfectly, so try to do so sparingly.
		~{x}, {y}, {right}, and {down} work exactly like in a bbox.
		~{damage} determines how much damage the attack does. If set to 0, the attack will not hit enemies.
		~{knockdown} is a binary value that determines if the enemy remains standing after the attack. 0 means yes, 1 means they end up flying.
		~{block} is a binary value which determines if an attack is unblockable.
		~{noflash} is a binary value which controls whether the flash is displayed. 0 means flash, 1 means no flash.
		~{pausetime} is an integer which will cause the attacker and attackee to be paused for {pausetime} if the attack hits something.
		~If you change or repeat an attack box's declaration later in the animation, you can create combos. However, a certain amount of time must pass before targets can be hit again (This can be avoided with 'fastattack'). Also, you must have at least one frame with a blank attack box (One set to 'attack	0	0	0	0	0	0	0	0	0') between the two frames or sets of frames which combo.
		~You can use negative numbers or numbers outside of the frame's edges.
		~Can be used multiple times in one animation to change hit areas mid-animation
		~When the attacking part of the animation is over, use 'attack	0	0	0	0	0	0	0	0	0'. Otherwise, the attack box will remain and can continue hitting people for the rest of the animation!

	blast	{x}	{y}	{right}	{down}	{damage}	{block}	{noflash}	{pausetime}
		~An attack box which can hit bboxes.
		~Unless otherwise specified, this works exactly like an 'attack' command.
		~blast attacks always knock the enemy down, and sends them flying farther than normal. A 'blast'ed enemy will also be able to hit other entities and knock them down.

	shock	{x}	{y}	{right}	{down}	{damage}	{knockdown}	{block}	{noflash}	{pausetime}
		~A shock attack box which can hit bboxes.
		~Unless otherwise specified, this works exactly like an 'attack' command.
		~If this attack hits an enemy or player, they will play their SPAIN or SHOCK animation.

	burn	{x}	{y}	{right}	{down}	{damage}	{knockdown}	{block}	{noflash}	{pausetime}
		~A burn attack box which can hit bboxes.
		~Unless otherwise specified, this works exactly like an 'attack' command.
		~If this attack hits an enemy or player, they will play their SPAIN or SHOCK animation.

	freeze	{x}	{y}	{right}	{down}	{damage}	{time}	{block}	{noflash}	{pausetime}
		~A paralyzing attack box which can hit bboxes.
		~Unless otherwise specified, this works exactly like an 'attack' command.
		~The target will be frozen solid for {time}. They will be unable to attack, move, use specials, etc. If they have an fmap, they will change to that pallete.
		~{time} is measured in seconds.
		~Any attacks to a frozen target will cause knockdown. Freeze attacks on their own do not knock enemies down (Unless they were frozen to begin with).

	steal	{x}	{y}	{right}	{down}	{damage}	{knockdown}	{block}	{noflash}	{pausetime}
		~An attack box which can hit bboxes.
		~Unless otherwise specified, this works exactly like an 'attack' command.
		~If this box hits a player or enemy, it will drain life from the target and give it to the attacker.

	move	{x}
		~Starting with the next frame, the entity will move forward (x) pixels with every new frame.
		~This value must be set to 0 again to stop the entity from moving any further during the animation.
		~You can use a negative value for (x) to move the entity backwards (Or slow their movement if they move automatically, like a jump attack).
		~Somewhere above 200, this value will allow an entity to run offscreen, out of play, and into oblivion. If you want to get rid of a sprite, this should fit the bill, but otherwise you'll have a suicidal entity. If you ARE trying to kill something, use a value like 1000, just in case.

	seta	{a}
		~Changes the entity's altitude off the ground to {a}.
		~The entity will remain at this altitude until changed again with 'seta' or the animation ends.
		~If the animation ends and the entity is off the ground, they will fall back down while playing their IDLE animation.

	platform	{upperleft}	{lowerleft}	{upperright}	{lowerright}	{depth}	{alt}
		~Turns an entity into a walkable platform.
		~The fields are all the same as in normal platforms defined in a stage's .txt file.
		~This can be changed on a per-frame basis to make platforms move up and down or shift left and right (or both, or neither).
		~If this entity moves with seta or move, any entities on top of it will also move up and down with it.
		~You can stack multiple platforms on top of each other. If you do, seta commands will be cumulative (that is, if you have a platform with seta 30 spawn on top of one with seta 50, it will be treated as being 50+30= 80 pixels off the ground, instead of 30 or 50.)

	energycost	{int}
		~Can be used in player's SPECIAL, SPECIAL2, and FREESPECIAL(#) animations.
		~When the attack is performed, (int) will be subtracted from the player's life.
		~If the user does not have more than {int} life remaining, they can't perform the attack.
		~Defaults to 6 for SPECIAL and 0 for anything else.

	sound	{path}
		~{path} points to a sound effect. The sound will be played as soon as the next frame is reached.
		~Only one sound can be played per animation. If you really want more, you can either fuse the two sounds into one file, or have the entity fire a projectile with no graphics which plays one of the sounds at the appropriate time.

	pshotframe	{frame}	{a}
		~If this command is present, the player will fire it's 'pshot' once frame {frame} is reached.
		~The projectile will be spawned at altitude {a}. Since you can't use 0 for {a}, if you want to have the projectile on the ground (and thus able to fall into pits it crosses) use -1 instead. It will spawn at 0, not -1.
		~The shot is defined by using the 'playshot' command.

	shootframe	{frame}	{a}
		~If this command is present, the enemy will fire it's 'shot' once frame {frame} is reached.
		~The projectile will be spawned at altitude {a}. Since you can't use 0 for {a}, if you want to have the projectile on the ground (and thus able to fall into pits it crosses) use -1 instead. It will spawn at 0, not -1.
		~The shot is defined by putting 'load shot' in the .txt file, or using the 'fireb' command.

	throwframe	{frame}	{a}
		~If this command is present, the enemy will throw it's 'star' or 'knife' once frame {frame} is reached.
		~The projectile will be spawned at altitude {a}. Since you can't use 0 for {a}, if you want to have the projectile on the ground (and thus able to fall into pits it crosses) use -1 instead. It will spawn at 0, not -1.
		~The projectile is defined by putting 'load star' or 'load knife' in the .txt file, or using the 'star' or 'knife' commands.
		~Knives will be used if the entity is on the ground. Three stars will be used if the entity is airborne.

	tossframe	{frame}	{a}
		~If this command is present, the enemy will throw it's 'bomb' once frame {frame} is reached.
		~The projectile will be spawned at altitude {a}.
		~The projectile is defined by putting 'load bomb' in the .txt file, or using the 'bomb' command.

	jumpframe	{frame}	{height}
		~If this command is present, the entity will perform a jump once frame {frame} is reached.
		~Only one jumpframe command counts- you can't jump more than once in an animation by putting more in, even if the entity lands before the next jump starts.
		~The style of jump depends on the characer performing the jump and the {height} value:
			Height is 0:	Player:	The jump is very low, but the character moves forward.
					Enemy:	The jump is high and vertical.
			Height > 0:	Player: The jump is {height} high, and vertical.
					Enemy:	The jump is {height} high, and moves forward.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Using Weapons:
	~Warning: Weapons require more memory! A new weapon is a new character, and it has to be loaded into memory at all times! That also means you should load the player with weapon models with load, not know, in MODELS.txt.
	~Weapons are lost every time you die or go to a new level (even if you don't go to a whole new stage).
	~Although you can change a player's max health when they pick up a weapon, doing so will not recover thier current life.
	~Weapons require several changes:

Original player file:
	~Add this line:	weapons {name1} {name2} {name3} {name4} {name5} {original name}
		~{name#} is the name of the model loaded in MODELS.txt which this character becomes when they pick up weapon #.
		~{original name} is the name of the character when it doesn't have any weapons equipped.

Player with weapon model:
	~Create a normal player file with the weapon model's data, but do not include any fields or animations which are the same as the original's. Don't worry if it's normally required, only include altered fields. The original .txt is basically "upgraded" with the new weapon .txt- fields which are different are replaced, new fields get added, and fields which are not mentioned are not changed.
	~You do need a name, though. And it has to match the name used in the original player's {name#} field.
	~This entity should have 'type none'. Do NOT give it 'type player'.

Item which gives you the weapon:
	~Set it up like a normal item, but give it
	subtype	weapon
and
	weapnum	{#}
where {#} is the number of the weapon which this item gives players (1-5).

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
System Files:
	flash.txt
		~A standard .txt file for an entity, but the only animation it needs is IDLE. 
		~It should have type none. It doesn't behave any different with any other type, though.
		~This graphic plays when an attack box of any kind hits a bbox.
		~The offset is the point at which the flash will be centered.
		~I would strongly advise NOT setting this to loop, for reasons that will become obvious fairly fast if you do.
		~BoR doesn't have a default location for this, so it must be loaded in MODELS.txt.
		~This can be overridden on a per-entity basis with various commands.

	data/SPRITES/font.gif
		~The most-often used font.
		~Characters are 9*9 boxes. There are repeated characters, some of which are used in specific situations, but I'm having trouble figuring out which is used where (If you know, tell me!).
		~OpenBoR fonts are not monospaced. That is, the space between two letters is determined by how wide the letter is. If your letters 'overlap', try placing a black outline around them.

	data/SPRITES/font2.gif
		~The font used when a selection is highlighted, and for new;y-added scores on the high score screen.
		~Characters are 9*9 boxes. There are repeated characters, some of which are used in specific situations, but I'm having trouble figuring out which is used where (If you know, tell me!).
		~OpenBoR fonts are not monospaced. That is, the space between two letters is determined by how wide the letter is. If your letters 'overlap', try placing a black outline around them.

	data/SPRITES/font3.gif
		~This font is used as a 'header' for most options list. It appears at the top of the difficulty selection menu and the options menu, mostly.
		~Characters are 9*9 boxes. There are repeated characters, some of which are used in specific situations, but I'm having trouble figuring out which is used where (If you know, tell me!).
		~OpenBoR fonts are not monospaced. That is, the space between two letters is determined by how wide the letter is. If your letters 'overlap', try placing a black outline around them.

	data/SPRITES/font4.gif
		~The large font used for 'game over' and 'next' screens, the timer, and a few other places.
		~There is a copy of this font in the OpenBoR GUI folder. It's used there as the normal font.
		~Characters are 13*17 boxes. There are repeated characters, some of which are used in specific situations, but I'm having trouble figuring out which is used where (If you know, tell me!).
		~OpenBoR fonts are not monospaced. That is, the space between two letters is determined by how wide the letter is. If your letters 'overlap', try placing a black outline around them.

	data/SPRITES/shadow{#}.gif
		~{#} is a number from 1 to 6.
		~This graphic is used as a shadow with negative alpha transparency.
		~You can make the shadows larger or smaller, but the shadow will not be recentered if you do, so you must change the entity's offsets accordingly.

	langpack.txt
		~This should be in the same folder as OpenBoR.exe.
		~You can change the fields in this file to change various message texts in OpenBoR. Experiment! ... or just check the .txt file I made to list the fields.

	data/SPRITES/arrow.gif
		~Normally, an arrow pointing rightward.
		~When a player has the ability to continue moving in the level, but does not do so, this graphic will flash on the right side of the screen to tell them to move.

	data/SPRITES/arrowl.gif
		~This works like the arrow.gif file, but it flashes on the left half in stages which scroll left.

	data/hiscore.gif
		~This is a .gif file which will be displayed as the background of the high score screen.
		~Defaults to an inky black nothing.

	data/scenes/gameover.txt
		~This is a cutscene file. If it exists, it will be played when all players lose all their lives and credits, or if a player chooses to quit during a game.
		~If this file isn't found, OpenBoR displays the default game over screen: the letters "GAME OVER" displayed in font 4.

	data/bgs/hiscore.gif
		~A background for the high score screen.
		~In order for this to display, 'hiscorebg' must be set to 1 in LEVELS.txt.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Cutscene Files:
	music	{path}	{loop}
		~{path} points to a .bor music file which will play.
		~{loop} determines if the music loops. 0 means no, 1 means yes.

	animation	{path}	{x}	{y}
		~{path} points to a (hopefully animated) .gif file which will be played.
		~{x} and {y} are the x and y positions of the top left corner of the .gif.
		~Max size is 320x240.

	silence	{int}
		~If {int} is 1, the current song will stop playing.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Level Files:
Level Design:
	type	{type}	{special}	{ffire}
		~Optional. {type} is a binary value which determines if the stage is a normal stage or a bonus stage.
		~Bonus stages end when all enemies and obstacles are destroyed, or when time runs out. Players won't lose a life if time runs out.
		~{special} is also a binary value. 0 means nothing, but if set to 1 then players will be unable to use their special attacks in this stage.
		~{ffire} controls friendly fire. 0 means players can hit each other, 1 means they can't. This overrides the settings in the options menu.

	music	{path}
		~Optional. 
		~{path} points to a .bor music file which will be played during the stage.

	bossmusic	{path}
		~Optional.
		~{path} points to a .bor music file which will be played when a boss appears.

	spawn1	{x}	{z}	{a}
		~Optional.
		~Sets the respawn position for Player 1.
		~This only changes the position when the player respawns after dying.
		~The variables set the x, z, and a positions. You probably guessed that, but just in case...
		~{x} is relative to the left edge of the screen. {z} is relative to the stage's minimum z value. {a} is relative to the ground.

	spawn2	{x}	{z}	{a}
		~Optional.
		~Sets the respawn position for Player 2.
		~This only changes the position when the player respawns after dying.
		~The variables set the x, z, and a positions.
		~{x} is relative to the left edge of the screen. {z} is relative to the stage's minimum z value. {a} is relative to the ground.

	direction	{dir}
		~Determines which direction the screen scrolls in.
		~{dir} can be left, up, or down. Technically, it can be almost anything, but only those three actually have an effect. If {dir} is anything else, it defaults to right.
		~up and down scroll automatically. You cannot scroll left or right in these stages. You must use groups to control enemy spawning. It's normally important to include time items in these stages.
		~left and right must be scrolled manually, like normal.

	bgspeed	{speed}	{dir}
		~Causes the background of the stage to scroll by automatically.
		~{value} should be a number from 0 to 30 or so. 0 means no movement, 1 means slow movement, and anything above that means faster movement.
		~{dir} controls the direction that the background moves in. 0 means right-to-left, 1 means left-to-right

	settime	{int}
		~This stage's time limit will be {int}.
		~If {int} is 0, the player will have unlimited time.
		~The timer resets every time a 'wait' group of enemies is cleared. Note that it doesn't reset in between groups, only waits!
		~Using 'settime 1' isn't funny.
		~Don't forget to use 'Time' items when needed!

	notime	{bi}
		~Determines whether or not the player can see the game timer.

	noslow	{bi}
		~Determines whether or not the game slows down after beating a boss.

	background	{path}
		~{path} points to a graphic file which will be visible behind all the sprites and panels.
		~The image used must have a width which is a multiple of 4 (ex. 4, 200, 128, not 3, 202, 130).
		~The default height is anything from 1 to 240.
		~The graphic automatically repeats if the stage is longer than the background.
		~Using the transparent color in backgrounds can lead to an interesting visual effect. Afterimages will be left by any and all graphics which pass over transparent sections. This isn't what you normally want, though.

	water	{path}	{warp}
		~Optional.
		~{path} points to a graphic file which will be used as a watery background.
		~the graphic appears at the {BGHeight}, which is defined with 'z' in LEVELS.txt.
		~If you use 'rock 0' or do not include the rock command, the water will be warped by a sine wave (It will slither back and forth). {warp} will determine how quickly the waving will occour.
		~If you use 'rock 1' in the same stage, the water will float past in parralax (The graphic gets larger as it approaches the playing area). {warp} will determine the speed.

	rock	{bi}
		~Optional.
		~0 means nothing. 1 means the level floats up and down slightly.

	mirror	{bi}
		~Optional.
		~Determines whether or not there is a mirror in the background.
		~0 means no. 1 means that sprites will have a "mirror" image drawn between the background and panels.

	panel	{norm}	{neon}	{scrn}
		~{norm}, {neon}, and {scrn} are paths which point to the normal, neon, and screen graphics for a panel. {neon} and {scrn} are optional fields. If you aren't using them, put the word 'none' in their place.
		~Panels are mostly used as the floor and walls of a screen.
		~Panels are normally 244 pixels high, but should be 256 if the stage is set to rock up and down. It may also need to be changed depending on the 'z' values set in LEVELS.txt
		~You can use whatever width you want, but it's a good idea to use simple values like 100, 150, or 360. It makes it much easier to add up the total length of the stage. 
		~All panels in a stage should have the same length and height.
		~If you overlap part of the image used in one panel with another, the computer will still try to draw both. Be nice to computers. Don't overlap panel layers.
		~Normal mode panel layers are just plain images. They have no visual effects.
		~Neon mode panel layers use 'pallete cycling': certain colors slowy change to different colors. To be more specific, colors 128 through 135 in the pallete will be cycled by two steps three times each second. I can't explain this much better, as I haven't done much successful experimenting with this layer.
		~Screen mode panel layers have alpha transparency. That means, they blend with the colors behind them, darker colors are more transparent, and brighter colors will blend less.
		~You can have up to 26 panels in a stage. They are labelled by OpenBoR from a to z. This is how OpenBoR thinks of them, don't actually put those letters in the panel declaration.

	frontpanel	{path}
		~{path} points to a panel layer which will be displayed on top of all other sprites and graphics except for the HUD. This can be used to make foregrounds.
		~frontpanels display in the order they are declared and repeat when they run out. You don't need to declare an order like with normal panels.

	order	{panel#}{panel#}{panel#}...
		~Determines the order of panels in a stage.
		~{panel#} is a letter a through z which corresponds to a panel. There should not be spaces between the panel declarations (ex. order abcabcada, not order a b c a b c a d a).
		~The same panel can be used more than once.
		~You can have up to 1000 panels ordered, but there's a catch: the engine can't read a line with 1000 characters in it (The max is somewhere around 100). To get around this, you can place the additional panels on another line with a separate order declaration, like this:
order	abcdefghij
order	klabcd
order	eeabcdef
		~That '...' at the end doesn't mean you should put a ... at the end. It means the pattern repeats like it has been repeating so far.
		~If you use 'direction left', panels will be displayed from left to right, starting with the last order and working up. In other words, the previous declaration would become 'eeabcdefijklabcdabcdefgh' instead of 'abcdefghijklabcdeeabcdef'.

	hole	{xpos}	{zpos}	{upperleft}	{lowerleft}	{upperright}	{lowerright}	{depth}
		~A 4-sided hole will be created at the specified point.
		~This is a bit complicated, so listen up! {xpos} and {zpos} are the x and z positions at which the hole is spawned (how far from the start of the stage, and how far from the top of the screen, respectively).
		~{lowerleft}, {upperleft}, {lowerright}, and {upperright} determine the x position of the four corners of the hole. These numbers are how far from the {xpos} the corners are, not how far from the start of the stage.
		~{depth} is the z depth of the hole: how far it stretches from the {zpos} to the top of the screen.
		~As an example, if you wanted to create a 10x40 parrallelagram ( /_/ ) hole at the bottom of the screen (256) at scroll position 500, you might put
 hole	500	256	0	10	10	20	40
		~If you create a hole which is not at the bottom of the screen, entities will be visible as they fall off the stage. Probably bad. So place an entity with type none right below the bottom of the hole which resembles the floor. This will cover up almost any entities which fall in the hole.
		~If used in a stage which scrolls left, the holes will start at the left edge of the starting screen and move right from there. So only holes which would appear in the first 320 or so pixels of the screen will actually be visible, and they'll be at the start of the stage.
		~The default values are 240, 12, 1, 200, 287, and 45, respectively.

	wall	{xpos}	{zpos}	{upperleft}	{lowerleft}	{upperright}	{lowerright}	{depth}{alt}
		~Creates a 4-sided wall or platform at the specified point.
		~All of the field except {alt} are the same as they are in holes.
		~{alt} is used to control the height of the platform. It's measured in pixels. So for a wall with 10 for it's {alt} value would be 10 pixels high, any entity on the platform would be displayed 10 pixels off the ground, and entities would need to jump at least 10 pixels off the ground to get on top of the wall.
		~If you want to make a wall which can't be jumped on, simply give it a {alt} value somewhere in the lower thousands. Very, very, VERY few entities should be able to jump on it.
		~In order for enemies to get on platforms higher than their current position, they need a JUMP animation with a range set for it, and/or an animation which lifts them off the ground.

	endhole	{bi}
		~Optional.
		~Determines if the rightmost edge of the stage is a pit.
		~1 means yes. 0 means no.
		~Don't use this if your stage scrolls left. Trust me on this one.

	blocked	{bi}
		~Optional.
		~Determines if the edge of the stage is a solid wall. 1 means yes. 0 means no.
		~Entities who hit the wall will stop moving.
		~This always appears on the right side of the screen, and if you choose 'scroll left' players will start inside the wall. They warp out when the player moves, but it still looks funny.
		~If you combine 'endhole' and 'blocked', you'll end up with a blocked exit with a pit behind it. You can only reach the pit by using the 'move' command in an attack or starting behind it with 'direction left' (Which is a very bad idea).

Level objects:
	spawn	{name}
		~{name} is the name of an entity defined in a .txt file which was loaded in MODELS.txt.
		~{name} will be spawned (created). Where and with what attributes are determined by the next set of fields.

	2pspawn	{bi}
		~If {bi} is set to 1, the entity is only spawned if there is more than one player playing.

	alias	{name}
		~The spawned entity will appear to have the name {name} in-game. For instance, if you used
spawn	Rugal
alias	Hotdog_Man
then when you reached Rugal in the stage, his name would be displayed as 'Hotdog Man'.
		~The rules from an entity's .txt file concerning names apply here, too. So use '_' instead of spaces.

	map	{pal}
		~{pal} is a number from 0 to 14 which corresponds to an entity's 'remap' pallete. The entity will use that pallete.

	health	{int}
		~{int} is a health value which will be used instead of the entity's normal health.

	2phealth	{int}
		~{int} is a health value which will be used instead of the entity's normal health, but only if there is more than one player playing.

	dying	{remap}	{health1}	{health2}
		~If this entity's health drops to or below {health1}, they will flash between their normal pallete and the {remap} pallete.
		~If their health drops to or below {health2}, they flash even faster.

	item	{name}
		~Optional.
		~When this entity dies, a {name} will instantly be spawned in it's place.
		~You can't make an entity drop multiple items.

	itemhealth	{int}
		~Optional.
		~Changes the health of a dropped entity to {int}

	itemmap	{int}
		~Optional.
		~Changes the pallete of a dropped entity to {int}

	itemalias	{name}
		~Optional.
		~Changes the name of a dropped entity to {name}

	itemhealth	{int}
		~Optional.
		~Changes the health of a dropped item to {int}

	2pitem	{name}
		~Optional.
		~Works just like 'item', except that this will only be spawned if there are two people playing.

	boss	{bi}
		~Optional.
		~If set to 0, nothing. If set to 1, the character is a boss. When a boss appears, the music will change to the boss music (if it was defined). Killing all the boss characters in a level will kill all other entities and will also end a stage automatically.

	flip	{bi}
		~Optional.
		~If set to 0, nada. If set to 1, the entity will face the opposite direction. Used for obstacles and traps most of the time, but it can also be used to make enemies who spawn on the left side of the screen face towards players from the start.
		~Can also be used for entities with subtype arrow to make them fly from left to right.

	coords	{x}	{y}
		~Determines the x and y positions on the screen where the entity will spawn.
		~{x} and {y} are relative to the screen's current position, NOT the actual position in terms of the level itself.
		~If {x} is between 0 and 320, and the entity is an enemy, it will magically fall out of the sky. Unless it has a SPAWN animation, in which case it'll play that.
		~If {x} is between 0 and 320, and the entity is an obstacle or item, it will magically appear out of thin air. Unless it has a SPAWN animation, in which case it'll play that.
		~In case you're wondering, the BoR playing field is, in bbox format,
			0	320	160	230
			Unless, of course, you've changed the {min} and {max} values in LEVELS.txt with 'z'. You can also place enemies outside those ranges, but they'll try to return to the playing field if you do.
		~Most projectiles will automatically die if their offset is more than 80 pixels offscreen left or right (their x value must stay between -80 and 400). Knives are the only exception: they can go up to 180 either way (-180 to 500). Other entities will also die if they move too far, but they have more leeway (Around 1000 in either direction). Keep that in mind while spawning characters.
		~Bikers should normally be spawned further out than other enemies. You'll probably want around 400 or -80 (But not more than -200 or 520, or they'll die).

	at	{pos}
		~For an entity to be spawned, the player must have scrolled to {pos} in the level.

	wait	
		~This isn't part of an entity's spawn. It doesn't take any arguments either. It should be followed by an 'at', though.
		~Screen scrolling will be stopped at {pos} in the 'at' command following the wait until all current enemies are killed.

	group	{min}	{max}
		~Also not an entity spawn, also should be followed by 'at'.
		~Causes entities to be spawned in groups. When the number of enemies goes below {min} (not equal to, below), entities will be spawned until there are {max} enemies onscreen or there aren't any more enemies to spawn in the group.
		~Group size declarations remain in effect until changed. So use a large group size like 'group	100	100' to "cancel" the grouping.
		~If you want to use both a wait and a group, you'll probably want to put the wait first, the group second, and then spawn entities.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Music Files:
	~Keep an eye on the file size. Music files tend to be the largest portion of BoR mods, frequently larger than the rest of the mod combined.
	~Some good ways to cut file size are to delete unneeded segments of the song, like silence at the start or end of the file or identical loops in video game tunes.
	~Chose some decent songs. If you've got different tastes in music, that's one thing, but just choosing random noise is something else. Make sure the music fits.
	~You'll need a program called WAV2BOR.exe, and some PCM 16-bit mono .wav files, preferably at 22 Khz. If you're having trouble understanding that last line, don't worry. Just open the .wav in Microsoft Sound Recorder and go to 'Save as...'. From there, find each of those options (PCM format, 16-bit mono at 22050 (22 Khz)) and select them.
	~Once you've got the files, place them all in a folder called W2B in your C: drive. This step wasn't neccessary, but if you're having trouble it might fix some problems.
	~Create a new .txt file, and give it a name. Add the following line for each .wav you want to convert:
wav2bor.exe	{wav}	{bor}	{artist}	{title}
	~{wav} is the name of the .wav file to be converted (make sure it has .wav on the end). {bor} is the file that will end up holding the .bor music. {artist} and {title} are optional fields which can be used for an artist name and song title. Or a dog's name and your favorite food. It doesn't really matter. If you do use them, remember that you must use underscores (_) instead of spaces ( ).

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Sound Files:
	data/sounds/beat1.wav
		~Played when an attack hits an entity's bbox.
		~Normally, this sound will be played slower depending on how much damage the attack deals. If this is a problem, you can disable this with the 'noslowfx' command.

	data/sounds/fall.wav
		~Played when an entity hits the floor after being knocked down.

	data/sounds/get.wav
		~Played when a player picks up an item.

	data/sounds/money.wav
		~Played when a player grabs a score item.

	data/sounds/jump.wav
		~Played when someone jumps.

	data/sounds/indirect.wav
		~Played when one character is flung into another with THROW.

	data/sounds/punch.wav
		~Played when a player uses an attack in their attack chain (Pressing attack from a standing position). Normally only heard if the attack misses.

	data/sounds/1up.wav
		~Played when the player gets a 1-up.

	data/sounds/timeover.wav
		~Played if the timer hits zero. Also played if all credits are lost.

	data/sounds/beep.wav
		~Played in menus (not in game) when you move up or down.

	data/sounds/beep2.wav
		~Played in menus (not in game) when you select an option.

	data/sounds/bike.wav
		~Required if you have bikers. Plays for bikers, of course.

	data/sounds/block.wav
		~Optional. Plays when an entity blocks an attack.

	~Just like the music, keep an eye on the file size.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
PAK File Making:
	~You'll need a program called PACKER.exe.
	~More will go here later. Sorry!
	~By the by, if you know how to create .PAK files, feel free to contribute...

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Troubleshooting:
NONFATAL:
If your mod isn't crashing, but it's still acting funny, check this list:
In Windows XP, sound isn't working, is garbled, or is delayed.
	~Try adjusting the frequency and bit depth in the options menu. If that doesn't work, try moving your Settings file to another folder and reopening OpenBoR. If that doesn't work, try downloading a program called VDMSound off a website (It should be free, don't let someone make you pay for it!). If that doesn't work, I don't have any more ideas. Sorry.
	~Also, in the case of delayed sounds, make sure that there is no silence before the sound/song starts. If the file has a second of silence before the sound actually plays, there's not much that will fix it besides using a sound editor (Like Window's free built-in Sound Recorder) to hack that silent portion off.

After downloading a new version of OpenBoR, my HUD (life bar, time, etc.) appear at the bottom of the screen and my options and controls are messed up!
	~Sometimes, the format of the file SETTINGS.SAV will be changed. When this happens, you'll need to delete the SETTINGS.SAV file you currently have in the same folder as OpenBoR and re-open OpenBoR.

My entities are a discolored box/have the wrong colors!
	~OpenBoR uses a pallete system. Make sure the entities have the correct pallete.

FATAL:
If your mod is crashing, right click on the OpenBoR.exe you use to run it. Click on properties, then go to the Program tab. Make sure there is NOT a check mark next to the box labeled "Close on Exit." Then get back to the game and try to do whatever it was that crashed the game again. This time, OpenBoR will have a little message for you.

Unable to open file '{path}'
	~Something is wrong with the file at {path}. Some possible known causes:
	~One of the file or folder names in the path is too long. BoR can only read from files and folders whose names are from one to eight letters long, not including the extension. For example, "BOB.txt", "12345678.gif", and "data/flip/flop.txt" are okay names. ".txt", "123456789.gif", and "data/nameistoolong/flop.txt" will all make the program spit out an error.

Failed to create colourmap from images        '{path1}' and        '{path2}'.
	~The game tried to make an alternate pallete (remap) of {path1} using the data in {path2}, but couldn't. Some possible known causes:
	~{path1} and/or {path2} do not exist. They may actually exist and just have the wrong name, so check your spelling if the files are there.
	~{path1} and {path2} are not based on the same image. They should be the exact same pictures EXCEPT that certain colors in one file have been replaced with another.

Command '{com}' not understood in file '{path}'
	~The line {com} is somewhere in {path}. However, OpenBoR does not have any code for handling {com}, and doesn't know what to do.
	~Check {com}'s spelling. For instance, it's colourselect, not colorselect.
	~Make sure you have the latest version of OpenBoR. New features won't work in older versions.

Unable to load file '' (may be out of memory)
	~This is a real sneaky error. It means that one of your .txt files which was just loaded doesn't end with a blank line.
	~To fix this, just go to the last line in the offending .txt file(s) and press enter once.
	~This will only crash OpenBoR when the problem file is actually loaded, not when it is 'known' while loading files at the start.

DOS/32A warning (9003): real mode interrupt vector had been modified: INT 43h
	~Roel (creator of the original BoR) finally found out some more about this. It's a Windows/DOS video mode emulation thing. Don't worry about it. It won't damage anything. I think.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Other Stuff:
Outside the Box:
	~OpenBoR adds a lot to an already powerful, simple engine. But you can take things even further with a little thought.
	~Just because they're called SHOCK, FREEZE and BURN doesn't mean they need to be bolts, icicles and flares. They could be other elements, or not even elements at all- ever noticed that most fighting games have separate graphics for low, mid, and high-level attacks? Or ever wanted a character to just sit still for a second or two? Among other things...
	~Text objects pause the game and can play an animation. You can use it for cutscenes which don't end the level, but this can lead to large file sizes, so only use this when needed.
	~Enemies can drop other enemies. That means you can create enemies with second forms.
	~An entity's offset, bbox, attack box, platform box, etc. don't need to overlap. Or even be close to one another. Maybe if you had an entity with, say, a wall-like platform which blocked movement and a bbox over a lever... 

Cutscenes:
	~There is a difference in the format for animated .gif files and not-animated .gif files. In other words, if you have a single-frame animated .gif, it would be read by OpenBoR differently than an identical non-animated .gif.
	~These scenes must have animated .gifs:		data/scenes/logo.txt
							data/scenes/gameover.txt
	~These scenes must have non-animated .gifs:	data/scenes/title.txt
							data/scenes/titleb.txt

Score:
	~When you hit an enemy, you get 5x the attack's damage in points.
	~THROWing an enemy will always earn you 21 points.
	~You get 5x the attack's power in the player's .txt file, not the damage dealt.
	~You get a one-up every 50,000 points.

Time:
	~Try to keep in mind how long it might take a player to beat a group of enemies or a boss. It feels kind of dissapointing to last 99 seconds against a high-health boss or endless stream of enemies, only to die from time over.
	~To create an item which recovers a player's time, name it Time in it's .txt file and in MODELS.txt and give it a 'health' and 'score' value of 0.

Projectiles:
	~Knives fly straight forward. They can fly over pits.
	~Stars can only be thrown during jumps. Three fly out at downward angles.
	~Shots slide straight forward. They fall into pits.
	~Playshots fly straight. They float over pits.
	~Bombs fly in an arc. They can be thrown over pits.

Player Swapping?
	~'load'ing a player character in a level's .txt file will cause the player's character to become the loaded character. You can't bring the character select screen back up, though.
	~You can allow players to "unlock" characters in-game by only "know"ing the player in MODELS.txt, but putting an item  which "load"s the entity in it's header. If a player grabs the item, they will be able to use the new character. This isn't saved when you close the game, though.

Transparency:
	~BoR does not support Alpha or normal transparency for custom sprites... but it does support "old school" transparency. Old school transparency isn't really making things transparent: you make them flash visible and invisible really quickly. Human eyes can't see the separate frames clearly enough, and merges the two images together.
	~You can see an example of this with my custom Guilty Gear XX hit sparks, located at http://www.angelfire.com/games5/js0/SolPage.html. 
	~Remember that, for the image to appear transparent (and not just like a flashing picture) you'll need to make the delay somewhere between 1 and 3~4. I would recommend 2 for most sprites, since 1 is blindingly fast.
	~This also takes up extra CPU power, since you're making it animate so fast and needs extra frames.
	~BoR does have a sprite with alpha transparency: the Steam graphic. It's the only one, though.
	~It also has a sprite with negative transpararency: Shadows.
	~Certain background panels and objects use transparency, but they aren't sprites.

Other notes:
	~Both OpenBoR.exe and WAV2BOR.exe only work with short file names. If you put them in directories with a file or folder name longer than 8 characters, they won't work.

Fun:
	~Try to keep your mod interesting. The original BoR engine had a lot of neat tricks and fun potential which was never realized, and OpenBoR increases those possibilities exponentially. Think carefully about what you do with them.
	~The little things make a difference. The secret enemy in the original BoR's elevator, the wacky names, the entire hidden stage...
	~There are more fighting styles than just the standard Hadoken fireball/uppercut/spin kick. Try different attacks out. There are some interesting styles and attacks out there. Variety is the spice of life, right?

Limits:
	~Maximum number of: 	sprite frames:	4000
				animations:	1000
				models:	200
				entities:	350
				panels per level:	52*
				frames per animation:	64
				weapons per player:	5
				remaps:		14
				name length:	40
				level spawns:	600
				panel order length:	2000
				hole spawns per level:	40
				levels:	100
				difficulty levels:	10
				sound effects:	128
				freespecials:	8

	*: Although the source code has been changed to allow up to 52 panels per stage, a way of using panels past 26 has not yet been decided upon. There are only 26 letters in the alphabet, after all. So you can only use 26.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
FAQ:
Q:	What do you mean by "entity?"
A:	It's anything you load in Models.txt. It's basically a .txt file which tells the game how to display and use a player, an enemy, a barrel, an apple, etc...

Q:	What's a "hud?"
A:	HUD: Heads-Up Display. It's what shows you life, your score, your player, etc. It's a display which gives you a heads-up as to what's going on.

Q:	Can I enter my initials on the high score screen?
A:	Nope, sorry.

Q:	Help! My settings are all wrong/My controls have randomnly changed/My high scores were replaced by gibberish!
A:	The settings file format may have changed. Try deleting or moving your settings.sav file in the same directory as OpenBoR and reopening OpenBoR.

Q:	My settings won't save on the Dreamcast version!
A:	This is a known issue. It seems the Dreamcast VMU (which is the only way to save on the DC) doesn't get along very well with OpenBoR, and getting them to work together would require too many major changes.

Q:	All your advice is for Windows! Windows sucks and is the work of the devil! How do I use this on other platforms?
A:	Sorry, but you're on your own there. The only OS's I've got are '98 first edition and XP Pro SP2, and I've never tried making a BoR CD for my Dreamcast. However, many other members of the OpenBoR community are pretty good at it, so try going to the OpenBoR forums for help.

Q:	Where is the DC/PS2/PSP/Windows/X-Box/GP32 version of OpenBoR?
A:	The DOS and DC (NTSC and PAL versions) are available from the OpenBoR website. The PS2, PSP, X-Box, Windows, and GP32 ports of the original BoR were all done by separate coders, none of whom have expressed interest in porting OpenBoR. Without skilled coders for those platforms, those ports will not be possible.

Q:	What is this DarkBoR/HoR/AotB thing I keep hearing about?
A:	DarkBoR is an alternate version of BoR which has several unique features such as an MP bar and enhanced weapons support. It is developed by Tails. HoR is an edit of BoR designed to create shooting games. It is developed by Lord_Ball. AotB is a "sequel" of sorts to the original BoR. The storyline and characters are new, but the basic gameplay will be like an upgraded version of the original BoR. It's being developed by Senile Team, creators of the original BoR.

Q:	Which version of BoR should I use?
A:	That's a question of opinion. Each has certain advantages.
	The original BoR is the only version with certain ports, such as Windows and X-Box.
	OpenBoR has many new features and backwards compatability, as well as correcting some errors.
	DarkBoR also adds new features, but a different set. If you want new features, compare the lists for OpenBoR and DarkBoR and decide which set you like more.
	HoR is for overhead/sideview shooters, so that's something of a different situation.
	AotB isn't out yet. So, um, it's not really a choice at the moment.
	Also remember that you may be able to create multiple versions, like how game companies release cross-platform games. That's extra work, though.

Q:	When is AotB going to be released?
A:	When it's done. Coding games is actually a difficult and annoying not-tons-of-fun task. Especially when you don't get paid. And even more so if people ask for demo versions or release dates. It's being worked on. It'll come when it's ready. Asking will at best do nothing and more often just slow things down.

Q:	Why are all your examples from Guilty Gear and/or Street Fighter games? What about King of Fighters/Darkstalkers/Vampire Savior/Mortal Kombat/Fatal Fury/Final Fight/Samurai Showdown/Marvel Vs Capcom/Primal Rage/Cyberbots/Art of Fighting/Fighter's History/Eternal Champions/Etc.?
A:	For Guilty Gear, fanboys will be fanboys. It's nothing personal, it's just my favorite series. For Street Fighter, I figure it's the one fighting game series ANY video game fan will have heard of.

Q:	Who made OpenBoR?
A:	For a brief history of OpenBoR, check a post by Kirby2000 on page 4 of the topic 'New Features for OpenBoR' in the 'BoR Mods' section of the Senile Team forums. It's fairly long and in-depth for a brief history.

Q:	Why am I not in the credits?!
A:	Either it's because you haven't yet done anything major for the OpenBoR/BoR community, or it's because I forgot or didn't know about it. If so, please let me know so I can add you. (No offense intended for anyone left out!)

Q:	I found an error in this guide.
A:	Then please, let me know so I can fix it.

Q:	I found an error in OpenBoR.
A:	Let CGRemakes know on the OpenBoR forums. Make sure to check the error multiple times in multiple ways to make sure it is an actual error. CGRemakes adds,
	1 - Please give specific information about how, what, when the bugs happen. A general explanation won't help locate the problem. 
	2 - Please keep in mind that others have coded features as well, and so you need to specify how long the bug has existed (if known) so I know if it's a bug I added or a bug that was already present. 
	3 - Don't report things as bugs because they are not coded to your liking.

Q:	I want something added to OpenBoR.
A:	CGRemakes is currently in charge of OpenBoR development. If you do want to ask him for new features, think first. How many people besides you would use the feature? Would it be possible to program? Would it make problems with older versions? Has someone else asked for something similar? If you still want to ask, be sure to do so nicely. CGRemakes is a nice guy, and he's not getting paid for this, so he deserves a little thanks, right?

Q:	I want to HELP add something to OpenBoR.
A:	Awesome! Head to the OpenBoR forums and let CGRemakes know. As a warning, even if your addition is really good, it may not be added. Backwards compatability, speed, memory, and DC compatability are all important factors in what gets added or not.

Q:	Can I make my own version of BoR/OpenBoR?
A:	Of course. If you're only making small, mod-specific changes (like changing the design of system menus), go ahead. If you're making larger changes (like new features or options), it would be nice if you mentioned it on the OpenBoR forums.

Q:	How do I make my own version of BoR/OpenBoR?
A:	This information will be available in the near future. 


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Credits:
	Senile Team:	Original BoR game.
	Roel:			Original BoR source code and engine, major improvements in OpenBoR code.
	Al Beastie:		Major OpenBoR programming, pretty much starting OpenBoR.
	Kirby2000		Major OpenBoR programming.
	Lord Ball:		Major OpenBoR programming.
	CGRemakes:		Major OpenBoR programming, Official OpenBoR website.
	Tails:		Major Dark/OpenBoR programming.
	drikobruschi:		Hi-score table code.
	Bloodbane:		Multiple corrections in the guide.
	Sega:			Original Streets of Rage design, concept, etc.
	SNK:			Original BoR graphics.
	Sega, Capcom, SNK, Konami, Tecmo, Treasure, Sammy,  etc.:
				For all the brawler games!
	Fugue:		Original author of this manual.
	The entire BoR and OpenBoR community:
				Keep making those games!

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Contact:
You can contact me specifically by registering for free on the OpenBoR forums <www.openbor.com or www.openbor.net> and sending me a PM or posting a question asking for help. 